Release 10.1A: OpenEdge Getting Started:
New and Revised Features

Additional details about the LOAD-RESULT-INTO technique

The new LOAD-RESULT-INTO temp-table approach balances some of the characteristics of the two previous approaches, enabling its functionality to also be extended. The LOAD-RESULT-INTO technique maintains some separation between the data and the foreign data source, allowing you to process the result sets quite independent of its database origin. Also, the result set definition is not contained within the schema holder. And, of key importance to users interested in the full data mapping to temp-tables, this technique easily bridges you to the Progress ProDataSets technology, as temp-tables are the data source for ProDataSets.

Figure 2–5 maps the functionality previously described for proc-text-buffer to native view retrieval methods into the LOAD-RESULT-INTO technique.

DEFINE VARIABLE tthndl AS HANDLE. CREATE TEMP-TABLE tthndl. RUN STORED-PROC send-sql-statement LOAD-RESULT-INTO tthndl      (“SELECT name, address, city, state, postal_code FROM customer WHERE      credit_limit>=500”). FOR EACH tthndl:      DISPLAY tthndl.name. END.

Figure 2–5: Load-result-into technique example

Unlike the proc-text-buffer and the native view techniques, the stored procedure result sets are processed within the context of the RUN STORED-PROC statement. Also, unlike the proc-text-buffer, the results are accessible as individual columns. And, unlike native views, there are no dependencies on the foreign data source. The FOR EACH block that follows the stored procedure execution simply iterates through a result set that was already established by the temp table tthndl. The tthndl is both dynamic and unprepared when used by this RUN STORED-PROC statement, but all the temp table states—static and dynamic, prepared and unprepared—are usable in the LOAD-RESULT-INTO phrase.